As software developers, we often focus on only a sub-set of the functionality of the systems which we develop and maintain. It is common practice for a small set of developers to "own" a section of a much larger system, allowing them to get a deep understanding of that component, which in turn allows them to efficiently dive into that portion of the code with little ramp-up time, making the larger team more efficient as a whole.
However, this developer specialization comes with some costs.
As humans, we often look for the shortest path to achieving our goals, so when a developer who knows a certain set of product features really well has a task to perform in that system, they are more likely to use the feature sets they know deeply to perform those tasks. This presents problem 1:
Software developers tend to know the portion of the system they work with very well, but have an atrophied understanding of the rest of the system.
Further, developers tend to have a specific set of use cases in mind when they create software and often get tunnel vision when they are using the system, not deviating from their preconceived expectations for how users will utilize those features. Thus, problem 2:
Software developers will box themselves into a specific user experience and not venture from that path.
However, with very rare exceptions, software developers do not write software for themselves. And the real users of the system have their own ideas and notions as to how the system should be used, often differing from the developers' viewpoint. This usability expectation mismatch leads the user to uncover bugs/unimplemented features and have a degraded user experience, since the developers did not have the users' usage patterns in mind.
So, how do we address these issues in order to improve the quality and user experiences of our software?
Let me share three experiences I've had along these lines during my career.
A Day in the Life of a User
This week at InRule, we made an investment in our product's quality by having the entire development team take part in a "Day in the Life" exercise where we were all given a real-world customer scenario, straight from one of our pre-sales engagements, and tasked with implementing a solution using our software.
Each developer went off on their own to implement their solution. Our product owner acted as our customer, answering any questions we might have about the requirements. We were allowed to ask others for help if we got stuck (although it was suggested we utilize the public help docs, etc, first, since our clients don't have direct access to our dev team). Six hours later, we all reconvened to discuss our findings and go over possible solutions.
So what was the result? Multiple bugs were found, several reoccurring usability issues uncovered, and every developer came away greatly increasing their understanding of our product's features and weaknesses. As a team, we now have a greater understanding of where we need to focus on improving usability, and where, as individuals, we have shortfalls in our understandings of the product as a whole. While this was a fairly expensive endeavor (we programmers aren't cheap), the leadership saw this as a worthy investment, as the product will improve, and in turn so will our customers' satisfaction level, as a direct result of this exercise.
Customer Service Shadow
Another approach that we tried a couple of times while I was at Wayport, which was much more of a service company, was to have the developers spend a day shadowing one of our call center reps, listening in on calls to hear customer's pain points firsthand, as well as how the support staff was able to diagnose and troubleshoot the systems. In this case, it exposed shortcomings for both our internal and external users' experiences, as well as helped the development staff understand where we need to better inform the support staff of existing functionality that would help improve their day-to-day job. So again, a win-win for everyone involved, helping to reduce the friction in our user's interaction with the software, and helping to keep the otherwise isolated developers informed of how users really use the system so that we can build better experiences going forward.
Everyone Cooks
My last anecdote is not software specific, but goes to the core of the point I'm trying to make. I spent two years working as a consultant within McDonald's corporate headquarters, and while there I learned of a part of their corporate on-boarding process that I thought was worth sharing. Given that everyone at McD corporate is there to support the individual stores' operations, every employee, from IT project managers, to accountants and lawyers, all had to spend two weeks working behind the counter at a McD restaurant -- cooking, taking inventory, cleaning, serving customers and living the daily ins and outs of the people they would be supporting for the rest of their time at the company. I was amazed at how much these experiences seemed to resonate with the McD folks, even years after they completed their stint in the stores.
If you have other ideas, feel free to leave them as comments.
Photo Credit: Michael Dales (Creative Commons License)